An internetwork is a collection of individual networks connected with intermediate networking devices that function as a single large network. Different networks can be interconnected by routers and other networking devices to create an internetwork.
A local area network (LAN) is a data network that covers a relatively small geographic area. It typically connects workstations, personal computers, printers and other devices. A wide area network (WAN) is a data communication network that covers a relatively broad geographic area. Wide area networks (WANS) interconnect LANs across normal telephone lines and, for instance, optical networks; thereby interconnecting geographically disposed users.
There is a need to protect data and resources from disclosure, to guarantee the authenticity of data, and to protect systems from network based attacks. More in detail, there is a need for confidentiality (protecting the contents of data from being read) integrity (protecting the data from being modified, which is a property that is independent of confidentiality), authentication (obtaining assurance about she actual sender of data), replay protection (guaranteeing that data is fresh, and not a copy of previously sent data), identity protection (keeping the identities of parties exchanging data secret from outsiders), high availability, i.e. denial-of-service protection (ensuring that the system functions even when under attack) and access control. IPSec is a technology providing most of these, but not all of them. (In particulars identity protection is not completely handled by IPSec, and neither is denial-of-service protection.)
The IP security protocols (IPSec) provides the capability to secure communications between arbitrary hosts, e.g. across a LAN, across private and public wide area networks (WANs) and across the internet IPSec can be used in different ways, such as for building secure virtual private networks, to gain a secure access to a company network, or to secure communication with other organisations, ensuring authentication and confidentiality and providing a key exchange mechanism. IPSec ensures confidentiality integrity, authentication, replay protection, limited traffic flow confidentiality, limited identity protection, and access control based on authenticated identities. Even if some applications already have built in security protocols, the use of IPSec further enhances the security.
IPSec can encrypt and/or authenticate traffic at IP level. Traffic going in to a WAN is typically compressed and encrypted and traffic coming from a WAN is decrypted and decompressed. IPSec is defined by certain documents, which contain rules for the IPSec architecture. The documents that define IPSec, are, for the time being, the Request For Comments (RFC) series of the Internet Engineering Task Force (IETF), in particular, RFCs 2401-2412.
Two protocols are used to provide security at the IP layer; an authentication protocol designated by the header of the protocol, Authentication Header (AH), and a combined encryption/authentication protocol designated by the format of the packet for that protocol, Encapsulating Security Payload (ESP) AH and ESP are however similar protocols, both operating by adding a protocol header. Both AH and ESP are vehicles for access control based on the distribution of cryptographic keys and the management of traffic flows related to these security protocols.
Security association (SA) is a key concept in the authentication and the confidentiality mechanisms for IP. A security association is a one-way relationship between a sender and a receiver that offers security services to the traffic carried on it if a secure two-way relationship is needed, then two security associations are required. If ESP and AH are combined, or if ESP and/or AH are applied more than once, the term SA bundle is used, meaning that two or more SAs are used. Thus, SA bundle refers to one or more SAs applied in sequence, e.g. by first performing an ESP protection, and then an AH protection. The SA bundle is the combination of all SAs used to secure a packet.
The term IPsec connection is used in what follows in place of an IPSec bundle of one or more security associations, or a pair of IPSec bundles-one bundle for each direction—of one or more security associations. This term thus covers both unidirectional and bi-directional traffic protection. There is no implication of symmetry of the directions, i.e., the algorithms and IPSec transforms used for each direction may be different.
A security association is uniquely identified by three parameters. The first one, the Security Parameters Index (SPI), is a bit string assigned to this SA The SPI is carried in AH and ESP headers to enable the receiving system to select the SA under which a received packet will be processed. IP destination address is the second parameter, which is the address of the destination end point of the SA, which may be an end user system or a network system such as a firewall or a router. The third parameter, the security protocol identifier indicates whether the association is an AH or ESP security association.
In each IPSec implementation, there is a nominal security association data base (SADB) that defines the parameters associated with each SA. A security association is normally defined by the following parameters. The Sequence Number Counter is a 32-bit value used to generate the sequence number field in AH or ESP headers. The Sequence Counter Overflow is a flag indicating whether overflow of the sequence number counter should generate an audible event and prevent further transmission of packets on this SA. An Anti-Replay Window is used to determine whether an inbound AH or ESP packet is a replay. AH information involves information about the authentication algorithm, keys and related parameters being used with AH. ESP information involves information of encryption and authentication algorithms, keys, initialisation vectors, and related parameters being used with IPSec. AH information consists of the authentication algorithm, keys and related parameters being used with AH. ESP information consists of encryption and authentication algorithms, keys, cryptographic initialisation vectors and related parameters being used with ESP. The sixth parameter, Lifetime of this Security Association, is a time-interval and/or byte-count after which this SA must be replaced with a new SA (and new SPI) or terminated plus an indication of which of these actions should occur. IPSec Protocol Mode is either tunnel or transport mode. Maximum Transfer Unit (MTU), an optional feature, defines the maximum size of a packet that can be transmitted without fragmentation. Optionally an MTU discovery protocol may be used to determine the actual MTU for a given route, however, such a protocol is optional.
Both AH and ESP support two modes used, transport and tunnel mode.
Transport mode provides protection primarily for upper layer protocols and extends to the payload of an IP packet Typically, transport mode is used for end-to-end communication between two hosts. Transport mode may be used in conjunction with a tunnelling protocol, other than IPSec tunnelling, to provide a tunnelling capability.
Tunnel mode provides protection to the entire IP packet and is usually used for sending messages through more than two components, although tunnel mode may also be used for end-to-end communication between two hosts. Tunnel mode is often used when one or both ends of a SA is a security gateway, such as a firewall or a router that implements IPSec. With tunnel mode, a number of hosts on networks behind firewalls may engage in secure communications without implementing IPSec. The unprotected packets generated by such hosts are tunnelled through external networks by tunnel mode SAs set up by the IPSec software in the firewall or secure router at boundary of the local network.
To achieve this, after the AH or ESP fields are added to the IP packet, the entire packet plus security fields are treated as the payload of a new outer IP packet with a new outer IP header. The entire original, or inner, packet travels through a tunnel from one point of an IP network to another: no routers along the way are able to examine the inner IP packet. Because the original packet is encapsulated, the new larger packet may have totally different source and destination addresses, adding to the security. In other words, the first step in protecting the packet using tunnel mode is to add a new IP header to the packet; thus the “IP|payload” packet becomes “IP|IP|payload”. The next step is to secure the packet using ESP and/or AH. In case of ESP, the resulting packet is “IP|ESP|IP|payload”. The whole inner packet is covered by the ESP and/or AH protection. AH also protects parts of the outer header, in addition to the whole inner packet. The IPSec tunnel mode operates e.g. in such a way that if a host on a network generates an IP packet with a destination address of another host on another network, the packet is routed from the originating host to a security gateway (SGW), firewall or other secure router at the boundary of the first network. The SGW or the like filters all outgoing packets to determine the need for IPSec processing. If this packet from the first host to another host requires IPSec, the firewall performs IPSec processing and encapsulates the packet in an outer IP header. The source IP address of this outer IP header is this firewall and the destination address may be a firewall that forms the boundary to the other local network. This packet is now routed to the other host's firewall with intermediate routers examining only the outer IP header At the other host firewall, the outer IP header is stripped off and the inner packet is delivered to the other host.
ESP in tunnel mode encrypts and optionally authenticates the entire inner IP packet, including the inner IP header AH in tunnel mode authenticates the entire inner IP packet, including the inner IP header, and selected portions of the outer IP header.
The key management portion of IPSec involves the determination and distribution of secret keys. The default automated key management protocol for IPSec is referred to as ISAKMP/Oakley and consists of the Oakley key determination protocol and Internet Security Association and Key Management Protocol (ISAKMP). Internet key exchange (IKE) is a newer name for the ISAKMP/Oakley protocol. IKE is based on the Diffie-Hellman algorithm and supports RSA signature authentication among other modes. IKE is an extensible protocol, and allows future and vendor-specific features to be added without compromising functionality.
IPSec has been designed to provide confidentiality, integrity, and replay protection for IP packets. However, IPSec is intended to work with static network topology, where hosts are fixed to certain subnetworks. For instance, when an IPSec tunnel has been formed by using Internet Key Exchange (IKE) protocol, the tunnel endpoints are fixed and remain constant. If IPSec is used with a mobile host, the IKE key exchange will have to be redone from every new visited network. This is problematic, because IKE key exchanges involve computationally expensive Diffie-Hellman key exchange algorithm calculations and possibly RSA calculations. Furthermore, the key exchange requires at least three round trips (six messages) if using the IKE aggressive mode followed by IKE quick mode, and nine messages if using IKE main mode followed by IKE quick mode. This may be a big problem in high latency networks, such as General Packet Radio Service (GPRS) regardless of the computational expenses.
In this text, the term mobility and mobile terminal does not only mean physical mobility, instead the term mobility is in the first hand meant moving from one network to another, which can be performed by a physically fixed terminal as well.
The problem with standard IPSec is thus that it has been designed for static connections. For instance, the end points of an IPSec tunnel mode SA are fixed. There is also no method for changing any of the parameters of an SA, other than by establishing a new SA that replaces the previous one. However, establishing SAs is costly in terms of both computation time and network latency.
An example of a specific scenario where these problems occur is described next in order to illustrate the problem.
In the scenario, there is a standard IPSec security gateway, which is used by a mobile terminal e.g. for remote access. The mobile terminal is mobile in the sense that it changes its network point of attachment frequently. A mobile terminal can in this text thus be physically fixed or mobile. Because it may be connected to networks administered by third parties, it may also have a point of attachment that uses private addresses—i.e., the network is behind a router that performs network address translation (NAT). In addition, the networks used by the mobile terminal for access may be wireless, and may have poor quality of service in terms of throughput and e.g. packet drop rate.
Standard IPSec does not work well in the scenario. Since IPSec connections are bound to fixed addresses, the mobile terminal must establish a new IPSec connection from each point of attachment. If an automated key exchange protocol, such as IKE, is used, setting up a new IPsec connection is costly in terms of computation and network latency, and may require a manual authentication phase (for instance, a one-time password). If IPSec connections are set up manually, there is considerable manual work involved in configuring the IPSec connection parameters.
Standard IPSec does e.g. not work through NAT devices at the moment. A standard IPSec NAT traversal protocol is currently being specified, but the security gateway in the scenario might not support an IPSec protocol extended in this way. Furthermore, the current IPSec NAT traversal protocols are not well suited to mobility.
There are no provisions for improving quality of service over wireless links in the standard IPSec protocol. If the access network suffers from high packet drop rates, the applications running in the mobile host and a host that the mobile terminal is communicating with will suffer from packet drops.
A known method of solving some of these problems is based on having an intermediate host between the mobile terminal and the IPSec security gateway. The intermediate host might be a Mobile IP home agent, that provides mobility for the connection between the mobile terminal and the home agent, while the connection from the mobile node to the security gateway is an ordinary IPSec connection. In this case, packets sent by an application in the mobile client are first processed by IPSec, and then by Mobile IP.
In the general case, this implies both Mobile IP and IPSec header fields for packets exchanged by the mobile terminal and the home agent. The Mobile IP headers are removed by the home agent prior to delivering packets to the security gateway, and added when delivering packets to the mobile terminal. Because of the use of two tunnelling protocols (Mobile IP and IPSec tunnelling), the solution is referred to as “double tunnelling” in this document.
The above method solves the mobility problem, at the cost of adding extra headers to packets. This may have a significant impact on networks that have low throughput such as the General Packet Radio System (GPRS).
Another known method is again to use an intermediate host between the mobile client and the IPSec security gateway. The intermediate host has an IPSec implementation that may support NAT traversal, and possibly some proprietary extensions for improving quality of service of the access network, for instance.
The mobile host would now establish an IPSec connection between itself and the intermediate host, and would also establish an IPSec connection between itself and the IPSec security gateway. This solution is similar to the first known method, except that two IPSec tunnels are used. It solves a different set of problems—for instance, NAT traversal—but also adds packet size overhead because of double IPsec tunnelling.
A third known method is to use a similar intermediate host as in the second known method, but establish an IPSec connection between the mobile terminal and the intermediate host, and another, separate IPSec connection between the intermediate host and the security gateway. The IPSec connection between the mobile terminal and the intermediate host may support NAT traversal, for instance, while the second IPSec connection does not need to.
When packets are sent by an application in the mobile terminal, the packets are IPSec-processed using the IPSec connection shared by the mobile terminal and the intermediate host. Upon receiving these packets, the intermediate host undoes the IPSec-processing. For instance, if the packet was encrypted, the intermediate host decrypts the packet. The original packet would now be revealed in plaintext to the intermediate host. After this, the intermediate host IPSec-processes the packet using the IPSec connection shared by the intermediate host and the security gateway, and forwards the packet to the security gateway.
This solution allows the use of an IPSec implementation that support NAT traversal, and possibly a number of other (possibly vendor specific) improvements, addressing problems such as the access network quality of service variations. Regardless of these added features, the IPSec security gateway remains unaware of the improvements, and is not required to implement any of the protocols involved in improving service. However, the solution has a major drawback: the IPsec packets are decrypted in the intermediate host, and thus possibly sensitive data is unprotected in the intermediate host.
Consider a business scenario where a single intermediate host provides improved service to a number of separate customer networks, each having its own standard IPSec security gateway. Having decrypted packets of various customer networks in plaintext form in the intermediate host is clearly a major security problem.
To summarise, the known solutions either employ extra tunnelling, causing extra packet size overhead, or use separate tunnels, causing potential security problems in the intermediate host(s) that terminate such tunnels.